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I. INTRODUCTION! 



Dynamic linking Provides a flexible and convenient wav tor resolving a 
procedure's symbolic references to external Procedures and data. It is dis- 
tinguished by when a symbolic reference is bound to the (virtual) address of 
the external object, viz. , bindinq is deferred until the first actual refer- 
ence during execution. Yet in spite of the significant benefits and tore than 
a decade to assimilate the technology, the Multics system remains as essen- 
tially the singular working example. Several authors of articles (11 and 
operating systems texts (2,31 imply that a major reason tor this limited use 
is the soecial hardware required. We have addressed this limitation and have 
develoned a dynamic linker design that requires no more hardware sunoort that 
is orovided by modern microcomputers. 

Background 

We have used Multics (41 as the standard for the dynamic linking capa- 
bilities we would like to provide. Multics has an integrated hardware and 
software design with the hardware features that strongly supoort dynamic link- 
ing being (1) indirect addressing through memory, (2) a linkage fault during 
indirection, (3) segmentation, and (4) demand paging. 

Mthough commercial microcomputers do not have the range of hardware 
support found in Multics, they are increasingly capable. This has naturally 
led to increased expectations for services, and extensive capabilities such as 
full-functioned languages (e.g. , PL/I) and mult inrogrammed, multiprocessor 
operating systems (51 are emerging. We believe that dynamic linking is an 
attractive addition to this growing set of system capabilities. 
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B. Objectives 



We want our design to Provide the usual benefits ot' dynamic linking. k 
process should include only those Procedures and data actually referenced dur- 
ing execution, vice those included in the Program. Similarly, during software 
development programs may be run with references to Procedures (e.g. , error 
routines) not yet coded. Fven when all the referenced objects are available, 
they should be allocated (nenotv) resources only it the object is actuallv 
used, without the user predicting the actual usage before Program execution. 

The dynamic linker oust not seriously degrade other capabilities ot the 
system. w e have taken care to accommodate (but not require) in-core sharing 
of (oure) procedures and data, mixed languages in a process, a flexible tile 
system, and a security kernel structure r 51 for the operating svstem. n ro- 
gramming generality is preserved in that a (dvnamically linked) external 
reference can be used whenever an internal reference can be used. 

Finally, we note that Performance has been a dominant consideration. It 
all Programs were interpreted rather than translated we clear Iv could simulate 
the Multics hardware support tor dynamic linking; however, tor reasons ot per- 
formance we have not chosen the interpreter approach. Our major Performance 
objective has been to reduce to an absolute minimum the processing overhead 
required tor the second and subsequent references to an external object. Much 
more processing is required for the first reference that must, ot course, 
create and save (tor subsequent references) the information on the binding 
from svnbolic reference to virtual address. The completion ot this first 
reference is at the heart ot dynamic linking. 
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tl. P\SIC CONCEPTS vni OYMVIIC LIMklMC 



Oynamic linking always occurs during the execution ot a procedure in the 
address snace ot a process. It results from the symbolic reterence to an 
(explicitly declared) external procedure or data object. mynanic linking 
inolicitly requires the notion of a segment, i.e. , a logical group ot informa- 
tion (external object) that retains distinct attributes (e.g. , symbolic name) 
tor the life of the process. Mthough hardware segmentation is not mandated, 
each segment has an identifier (unique in each process) that we will call the 
segment number, h segment number and an offset within the segment constitute 
a virtual address that can be used to reterence a specific location. 

On a procedure's first reference (in a process) to an external object 
the dynamic linker, with support from the operating system, computes the vir- 
tual address corresponding to the symbolic reterence. The linker stores this 
binding in what we call a link. We then say the link is ''snapped", and subse- 
quent references are made through this snapped link without use of the linker. 
We will next examine conceptually the functions and data bases that make up 
the linker, and the rationale for them. 

External Procedures 

Consider what happens when a procedure segment <Caller> executes the 
first reference in a process corresponding to the source statement: 

CML Target 

<Caller>'s object code is typically envisioned as containing: 

CM.L (virtual address of the entry into <Tarqet>) (1) 

at the time of execution, however, until <Target> is linked this is not 
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feasible, since its virtual address is not known. We might alternatively con- 
sider translatinq the source into 

TALL <Linker> ("Target”) ( 7 ) 

where <Linker> is a orocedure sequent that calls on the underlying ooerating 
systen to tind the virtual address ot the entry tor the sequent named "Tar- 
get". 

•\tter detetrnininq the virtual address of <Target> , the linker could 
"snao the link" by overwritinq statement ( 7 ) in <Caller>'s object code with 
statement (1) , a call to the <Tarqet>. This is essentially what is done in 
the traditional (static) linking loader r 11 . However, to do this dynamically 
tor a running orogram makes <Caller> immure, in violation ot our design cri- 
teria. To address this we follow the Multics [41 examole, introducing the 
concent ot a linkage segment and a linkage oointer that ooints to the section 
(linkage table) in it tor <Caller>. 

Hvery process has a distinct (never shared) linkage table which contains 
an outgoing link tor each external reference bv <Caller>. The outgoing link 
tor the reference to <Tarqet> can be at a fixed offset (at translation) from 
the linkage oointer. Thus the object code ot the oure orocedure <Taller> can 
be ot the form: 

CVX (Linkage_oo inter + <Target> link oftset) (.3) 

The outgoing link is designed to invoke <Linker> on the first reference with 
something similar to statement (l) above, 'the linker then modifies (i.e. , 
snaos) the outgoing link to invoke <Target"> on subsequent references. 

It might seem that the snaooed link should merely be ot the form ot 
statement ( 7 ) above. However, a significant otoblem arises, ’itter the 
transfer ot control to <Target> we, of course, exoect the linkage oointer to 
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point to the linkage cable tor <Targec>, not <Caller>. 'Jntortunately , the 
(cure) code ot <TargeO cannot orooerly load the linkage Pointer, because the 
appropriate virtual address is unknown at translation time. Theretore, the 
linker includes in the linkage table ot CTarget^ an incoming link tor the 
entrv to <Target>. Thus the orooer form for the outgoing link from <Caller> 
is: 

C\LL (<Tarqet> incoming link) (4) 

This snapped incoming link contains a statement to load the linkage oointer, 
followed by the form of statement (l) to invoke <Target>. This comoletes the 
invocation and dynamic linking of the external Procedure <Target>. 

B. External Data 

\n external data reference has many similarities to the above. Consider 
the reference in <Caller> corresponding to the source statement: 
pointer := »iDDRBSS (Data) 

The pure code in <Caller> will be very similar to statement (3) for the same 
reasons; in particular we expect the form: 

CM.L (Linkage_Po inter + <Data> link offset) (5) 

The unsnaooed link in <Caller>'s linkage table will be similar to state- 
ment (2) tor procedures. In Particular the form 

C\LL <Linker> ("Data") (B) 

will invoke the linker to obtain the virtual address of <Data> and snap the 
link. The snapped link is much simpler than for procedures. We need some- 
thing of the form: 



RBT'JRM (virtual address of <Data>) 



(7) 



This comlec.es the reference to and dynamic linking ot the external data seq- 



uent . 



III. T'!T MICTJCO^'JT^R "5YMAMIT LIWkTh OTTITN 

A. The Tteos in Tstablishinq a Link 

having examined the basic concents of a dynamic linker, we will now 
investigate the features ot a desiqn for its realization. Once aqain the 
stems (figure Id necessary to dynamically link some external orocedure <Tar- 
qetl entrv_name> (l) to orocedure <Taller> will be followed, but emnhasis will 
be olaced on desiqn details vice linking concents. 

1. Invoking the Linker 

When <Taller>’s source code is translated, any external reference to 
<Tarqet> will be translated into code which transfers the execution ooint to 
an outgoing link in <Taller>’s linkage table (Taller. link) . Translated code 
will vary from system to svstem; however, co.nceotually we desire to have a 
nure orocedure (<Taller>’s object code) call some imnure orocedure 

(Taller. link) . This will allow us at some later ooint in the linking orocess 
to convert the initialized outgoing link in Taller. link from code which 
invokes the linker to code which will result in the invocation ot CTargetl 
encrv_name>. 

we have mentioned that the outgoing link is initialized to invoke the 
linker. One method to do this would be tor the outgoing link to oroduce a 

(l) Tntry_name reoresents a label within <Tarqet> which can be referenced bv 
an external orocedure. An entry ooint is an offset within <Target> associated 
with some entry name. 
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Table 



hardware fault which will invoke the linker as a fault handler. 



(This 



represents the most qenerai ot the methods available and is the method used in 
duitics.) however, barrinq this capability, the linker mav be invoked via a 
direct jump in the outqoinq link. In both these methods the linker would be 
passed the ottset ot the svnbolic name <Tarqet! entrv_name> in <Taller>'s svm- 
bolic name table (Caller. sym) . (\n object's svnbolic name table stores the 
symbolic names of all external references in a Procedure. 'idditionally it 
will be used to retain entry names and their associated entry points utilized 
within the procedure.) third mechanism to invoke the linker is via an 
explicit call in <Caller>'s source code oassinq to the linker the symbolic 
name of the object to be linked as a actual parameter. (^his represents a 
special case which will be discussed later.) 

2 . Cnaeoinq the Link 

The question naturally arises of how the linker knows where Caller. svm 
is located. We have Provided a mechanism to resolve this problem bv olacinq 
the virtual address ot an object's svnbolic name table in a header in the 
object’s linkaqe table. (We can always find an object’s linkaqe table since 
we propose to store a Pointer to it in a linkaqe address table.) Thus the 
linker can access the CTarqet! entry_name> by utilizinq the virtual address of 
the symbolic name table (from the linkaqe table header) and the ottset it was 
passed as a formal Parameter. 

The linker will then pass the symbolic name <Target> to a module in the 
supervisor called the address space manaqer (which will be discussed in more 
detail later) . \t this Point we will consider the address space manaqer a 
routine which, when passed a symbolic name, enters the object associated with 
that symbolic name in the address space of the executing Process and returns 
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to the linker the segnent number assigned to that object. 

how that we know the segnent number ot <Target>, we can generate a con- 
olete virtual address tor CTargetl entty_name> by accessing the entry Point 
into CTargetl associated with ’entry name' . Recall that the symbolic name 
table of an object contains not only the symbolic names of external refer- 
ences, but also entry names (and their associated entry points) into the 
object. Thus it we can access Target. sym we can find the entry point associ- 
ated with 'entry_name' . When the segment number of <Target> is returned to 
the linker, the linker will construct a linkage table for <Target> (if one 
does not already exist) to allow <Target> to engage in dynamic linking. Since 
the header ot Target. link contains the virtual address of Target. sym, we can 
find the entry noint corresoonding to 'entry_name' . 

We now have a virtual address (of the form <segment number I 
entry_point» and could invoke <Target| entry_name> at this noint. However, 
we would like to retain this virtual address to simolify subsequent invoca- 
tions ot CTargetl entry_name>. we can accomolish this goal by storing the 
virtual address ot CTargetl entrv_name> in Target. link. *\n incoming link has 
been set aside for this purpose and we can transfer control to this incoming 
link on subsequent calls by renlacing the jump to the linker found in the out- 
going link (in Caller. link) with a jumo to the incoming link (for <Targetl 
entry_name» . Thus subsequent calls will follow the sequence shown in figure 
2 . 

Recall that the linkage pointer is used to indicate the start of the 
currently executing Procedure's linkage table. Thus when we start executing 
in CTarget>, we want the linkage Dointer to point to Target. link. The incom- 
ing link for <Target| entry_nane> will be used to set the linkage pointer 
(nrior to transferring control to CTargetl entry_name» . This implies chat 
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when <Caller> calls an outgoing link the linkage oointer (which ooints to 
Caller. link) must be saved and furthermore nust be restored when the orocess 
execution ooint returns from <Tarqet> to <Caller>. This 'may be done automati- 
cally by the hardware CkLL/RCTJRM sequence or exolicitlv by the object code in 
<Caller>. 

3. Linking Rata 

The stens to link data differ slightly from those for linking pro- 
cedures. fundamentally , data is not executed and does not, therefore, have 
the canability to initiate dynamic linking. Thus it <Caller> were to refer- 
ence some data object, COatal entry _nane>, instead of invoking <hata| entry- 
name> all we really want to know is its virtual address, We therefore prooose 
that when snapoed, the outgoing link tor <Data| entry_name> will load some 
oointer register with the virtual address of <Data| entry_name> and then 
return to <Caller>. The sequence tor subsequent references to <Data| entry 
name> is shown in ^iqure 3. 

We note that the use of entry names within data imolies that the data 
must undergo a translation and have a symbolic name table and linkage table. 
These two items may be merged into one structure since the data linkage table 
consist of a header which (at this ooint) only contains a oointer to the data 
symbolic name table. 
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Fi g. 3 - Sequence of events for subsequent references to Data ! Entry_Name . 



R. 'Jnl inking 



In a microcomputer environment, there nay exist a limited number of seg- 
ments available tor use by a orocess (2). To orohibit this trom limiting the 
size ot programs, we may choose to unlink objects trom an address soace in 
order to allow the dynamic linking ot n ew objects to the orocess. 

1. fundamentals of 'Jnlinking 

Conceotually unlinking is a trivial orocess but may include pitfalls 
which must be taken into account. To unlink, an object is selected tor remo- 
val, the object's entry in the linkage address table is erased, and all outgo- 
ing links to the object are reset to their presnapoed format. This imolies 
two major points. First, any data required to reset an outgoing link must 
either be accessible by some means or stored in the outgoing link itself. 
Secondly, we must be able to find each snapped, outgoing link. It is proposed 
that a linked list ot outgoing links referring to an object be formed with a 
Pointer to the start of this linked list stored in the object's linkage table 
header. Thus, in the trivial case, unlinking an object consist of erasing the 
object's entry in the linkage address table, resetting each outgoing link in 
the object's linked list, and finally deleting the object and its linkage 
table from the process address space. 

2. Resolving addressing in the Combined Linkage Table 

Recall that we said there were pitfalls involved in unlinking. These 
arise from how an object's linkage table is entered in a process address 

(2) As an example, the 23000 microprocessor [71 with one Memory Management 
Unit allows a maximum of 04 segments, some of which must be assigned to the 
operating system. 
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space. Observe that it we are concerned with unlinking, there are not ade- 
quate segments available to assign each linkage table a unique segment number. 
It is proposed that in such an environment, individual linkage tables be com- 
bined into a single segment which we will call the combined linkage table. 

Oven though the combined linkage table conserves segments, it creates 
addressing Problems which must be taken into account. It, when removing a 
deleted object's linkage table from the combined linkage table, a compaction 
of the combined linkage table is Performed, some remaining linkage tables may 
be relocated. 

This relocation requires the following three addressing problems be 
resolved: (1) a relocated linkage table must have its entry in the linkage 
address table updated, (P) outgoing links which transfer control to an incom- 
ing link in a relocated linkage table must be updated, (3) nodes of an 
(unlinker) linked list pointing to outgoing links in a relocated linkage table 
must be updated. 

\ fourth addressing Problem which must be resolved involves the removed 
object's linkage table, "ach outgoing link in this linkage table is a node in 
a linked list and must be deleted from that linked list Prior to removing the 
linkage table from the process address space. (We note that a doubly linked 
or circular linked list of outgoing links is helpful in resolving these last 
two addressing Problems.) 

3. Selecting an Object for Removal 

\ brief comment is in order concerning the selection of an object tor 
removal. \ procedure cannot be unlinked and removed from the address space if 
it has a current activation record since this would break the integrity of the 
return sequence from a series of one or more procedure calls. Therefore a 
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mechanise muse be deveiooed to test tor this condition orior to selecting an 
object tor removal. This implies, tor examole, that the initial program can- 
not be unlinked since it is always either executing or in the return sequence. 

IV. SYSTEM SH DO 0HT 

We should now like to brietly discuss operating system support tor 
dynamic linking. It is felt that the capabilities discussed either already 
exist or are imolementable in most microcomputers. 

The address Soace Manager 

The address space manager serves as an interface between the dynamic 
linker and the ooerating system. It will call on ^ile System Management and 
(in some cases) Memory Management to obtain data which allows it to convert 
the symbolic name of an object into an addressable entity. Having done this, 
the address space manager will save this data in a table (which we will call 
the Process reference table) to orevent unnecessary invocations of ooerating 
system routines for subsequent request to make an object addressable by a pro- 
cess. We note that the process reference table is a 'oer orocess’ data struc- 
ture and each object entered in it has a unique set of attributes (such as 
segment number, access rights, etc.) with resoect to that process. 

When massed a symbolic name, the address space manager must be able to 
access the object associated with that symbolic name in order to make the 
object addressable by the Process. The address space manager will return to 
the dynamic linker a unique process-identifier associated with that object. 
This object identifier has been assumed to be the segment number assigned to 
the object, however conceptually all an object identifier must do is to allow 



the linger (and che user Process) co address che object in some fashion. 

R. Translator Support 

Recall that the linger, usin'} some tornat or template, must build a 
linkage table tor each object when that object is entered in the process 
address space. The existence ot this template and additionally, the existence 
ot the symbolic name table, inolv that the translator used must support 
dynamic linking by not only translating external references and recognizing 
entry names, but also by constructing a linkage table template and symbolic 
name table tor the translated object. \s will be sho'vn, it is reasonable to 
assume that a translator can be designed (or modified) with this capability 
since, in general, all data necessary to construct these two items is either 
easily computable or available in the translator's symbol table. 

1. The Symbolic Marne Table 

The symbolic name table (figure 4) contains an entrv tor each unique 
external reterence and entry name. In addition, the linkage table offset ot 
the corresponding link (i.e., outgoing and incoming links) tor each symbolic 
name table entr/ should be stored with that entry. u 'e note that this is man- 
datory tor entry names; however, tor external references, the addition ot the 
(outgoing) link offset is only convenient since it removes the requirement for 
the linker to store this information. 

It is reasonable to ask where the symbolic name table is located in a 
process address space. Recall that tor the data object <bata> , we have sug- 
gested that hata.sym be appended to Data. link. (This implementation allows 
<Data> to be based at offset zero and to grow dynamically.) b'e could use this 
solution tor a procedure also; however, since the symbolic name table does not 
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change, a seoarane cony tor each orocess is not needed. \ reasonable solution 
therefore would he to aooend the symbolic name table to the end of a (oure) 
orocedure's object code. 

7. The Linkage Table Tenolate 

The linkage table tenolate ( p igure 5) should reflect the exact format of 
an initialized linkage table with one exceotion. We have stated chat the 
header of a linkage table contains the virtual address of that object's sym- 
bolic name table yet at translation time the segment number of the symbolic 
name table is unknown. Therefore, we must construct this virtual address when 
the linkage table of an object is built. It the symbolic name cable is a mart 
of the object code, its virtual address can be commuted (given we know the 
offset of the symbolic name table in the object code) when the object's seg- 
ment number is obtained from the address soace manager. It the symbolic name 
table is a mart of the linkage table, we can obtain the linkage table segment 
number via the linkage address table. 

Notice that the header of figure 5 includes an entry reflecting the size 
of the linkage table. This renresents useful information it an unlinker is 
inolemented (by nroviding the unlinker with the size of a linkage table to be 
removed) and may orovide useful data when loading a linkage table in a orocess 
address soace. 

9y building the symbolic name table first, the construction of the body 
of a temolate becomes quite trivial for the translator, '^e note that there is 
a one-to-one manning between entries in the linkage table and the symbolic 
name table. Therefore the tenolate can be easily constructed by scanning the 
symbolic name table and initializing a link compatible with each narticular 
symbolic name table entry, \s each link is initialized, we can also enter its 
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link offset into its resoective symbolic nane table entry. 

It is reasonable to ask '-/here in a system the linkaqe table tenolate 
should be located. It is suggested that unless demand oaqinq is available, a 
separate tile tor the tenolate be created. This will allow the construction 
of a linkage table without requirinq that the tenolate be entered in a orocess 
address soace. In a demand oaqinq environment, the linkage table tenolate can 
be a oart of the object code and once it has been utilized to construct the 
linkaqe table, it will be 'oaqed out' of main memory since it will not be 
further referenced. 

C. D rocess Initialization 

Much work by Tanson [0 ,91 has been devoted to orocess initialization 
includinq a comolete descriotion of how the dynamic linker and the ooeratinq 
system are linked in a multi-domain environment. Our desiqo has been quided 
by these results. It should be noted that orocess initialization must include 
the orocess reference table and linkaqe address table. '->fith resoect to a 
user's oroqram, process initialization in a dynamic linkinq environment 
differs only in that the linkaqe table tor the user oroqram must be entered in 
the orocess address soace and the linkaqe oointer initialized orior to com- 
mencing oroqram execution. 

V. LIMXiqq WITHOUT THVJSIATOh S'I OD OPT 

Having implied that translator sunoort is necessarv to realize dynamic 
linkinq, we would like to summarize an implementation in an environment where 
this condition does not hold; the imolementation details have been qiven else- 
where [101 . It is felt that a linker in this environment should meet certain 
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fundamental requirements, ^irst, we would like to use the same dynamic linker 
to link both (translator) suooorted and unsuooorted objects thus requirinq 
onlv one linker and additionally allowing a orocess to utilize both object 
tyoes. Mso , we do not wish to have to exolicitlv declare in our source code 
an external object to be suooorted or unsuooorted since, it' that object is 
retranslated with a type change (e.g. , unsuooorted to supoorted) , all pro- 
cedures referring to that object would have to be retranslated also. (This 
implies that the linker must be able to differentiate between supported and 
unsuooorted objects.) 

-V The Interface Module 

Recall that we have offered an exolicit call to the linker in a 
orocedure's source code as a mechanism for linker invocation such as 
CALL CLIMO (Target) 

In this examole, <LM> is a nodule which is statically linked to a orocess 
and serves as an interface between the orocess and the dynamic linker. Con- 
ceotually, <LIM r <> must carrv out those functions which, in a (translator) suo- 
oorted system involve the translator. 

B. Linking 'Insuooorted Objects 

'\'e will now investigate the stems necessary to link the unsuooorted 
object <Target> to the unsuooorted orocedure <Caller> (figure *>) . 

'-'/hen <LIMk> is called it will enter <Target> in the next free location 
in Caller. sym and will build an initialized outgoing link tor ‘(Target^ in 
Caller. link. (If <Target> already has an entry in Caller. sym, it also has a 
snaoped link and all that is required is to execute the snaoped link.) <LIMK> 
will then load CTargetVs parameters into the system according to translator 
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Fig. 6 - Sequence of events for linking unsupported objects. 



conventions and execute the outgoing lin'<. 

''/hen the linker identities <Target> as unsupported, it will cause a 
block ot virtual memory to be allocated to serve as Target. link and Target. svrn 
(since <Target> has neither a svmbolic name table nor linkage table template) . 
Once Target. link and Target. syn have been initialized, the linker will enter 
<Target> as the only entry name in Target. syn and complete the link by snao- 
oing the incoming link in Target. link (provided <Target> is a Procedure). 

C. The Interface Linkage Pointer 

We canrro-tr expect that an unsupported translator will know that the link- 
age pointer hardware register is not available tor general use and therefore 
must assume that it cannot be used to Point to the linkage table of an execut- 
ing unsupported procedure. We therefore propose that an interface linkage 
pointer be established (in software) by <LIM T <> to duplicate the functions of 
the hardware linkage pointer. 

We should like to observe two important points. ^irst, the incoming 
link to <Target> must set the interface linkage pointer to point to 
Target. link vice the hardware linkage Pointer. Second, it a process executes 
both supported and unsupported Procedures, the first Procedure executed must 
be supported since this ensures that the hardware linkage pointer is saved 
before it can be subject to general use by an unsupported Procedure. 

0. The Disadvantages of ’Jnsunoorted Dynamic Linking 

There are tour major disadvantages when linking in an unsupported 
environment. To begin with, subsequent references to a linked object will be 
executed much slower than in a supported system since housekeeping functions 
associated with linking are carried out by software routines vice object 
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(machine) code. Secondly, we have not orooose^ a mechanism to oass external 
orocedures to subroutines as actual oarameters. \ third disadvantage relates 
to nultinle entry ooints. Since the identification of entrv names and their 
associated entry ooints requires translator suooort, an unsuooorted object can 
only be accessed at one entry ooint (viz. . its starting location) . \ fourth 
disadvantaqe is that external data will be limited to a based variable similar 
to those found in °L/I or PL/M since <LIMk> can only return to the ooint of 
call a oointer to the external data. 

VI. TO'W: IMPLISM’IOMS 

Having discussed the design of a dynanic linger to execute on currently 
available nicroorocessors , we would like to examine hardware features which 
are advantageous in a dynamic linking environment. The hardware features dis- 
cussed can be classified into two general grouns: those which influence the 
design of the dynamic linker and those which affect the system oerformance bv 
imorovinq execution soeed. 

\. Hardware features \ffecting Linking besiqn 

'•re will discuss four hard-rare features which affect the design of a 
dynamic linker. To begin with, the abilitv to invoke the linker via a 
hardware fault ensures that a comoletelv general design can be imolemented. 
'•'ithout this caoability, a link must be snaooed when external data is massed 
as an actual oarameter to a subroutine (viz. , when the call is executed) , 
imolving that a link may be snaooed orior to first reference. The second 
desirable hardware feature involves the caoability to reference external 
objects via indirect addressing. It this feature exists, snaooed outgoing 
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links are sinoly virtual addresses tor indirect addressinq instructions. 
(Multics utilises indirect addressinq and a lin’<aqe fault on indirection in 
the implementation ot its dynamic linker [hi.) 

third intluencinq feature involves the size ot (hardware) virtual 
memory. '\ r e note it an adequate nunber of segments exist (assuming each seq- 
ment is of reasonable size) , it may not be necessary to inclement an unlinker. 
(We can always conserve seqment numbers by combininq smaller objects into one 
seqment orior to execution and referencinq each object via an entry ooint.) 
The final feature has already been mentioned and is the ability to save and 
restore the linkage pointer as a part ot the microprocessor's CkLL and 
conventions. 

3. Performance Considerations 

Mong the lines ot system performance we will discuss two hardware 
features: the hardware relocatability ot code and hardware segmentation. 
These are supported by modem microprocessors such as the Ziloq ZCOhh [71 and 
the Intel successor [111. 

With respect to hardware relocatability, we note that one must have 
relocatable Procedure segments to implement a dynamic linker since at the 
start of Program execution, there exist no bindings between procedures and 
process virtual addresses. Therefore, the more efficiently procedures can be 
relocated (viz. , hardware relocation) , the better system performance will be. 

We have maintained that a dynamic linker can be implemented without 
hardware segmentation as long as individual objects can be referenced as logi- 
cal entities (i.e., segments). This implies that many functions intrinsic to 
a segmented system must be available in a dynamic linking environment. It is 
only logical, therefore, to conclude that it is advantageous to have hardware 



segmentation. In particular , the in-core sharing ot objects (e.g. , oure Pro- 
cedures) in a multiprogramming environment is extremely difficult to implement 
without the support ot hardware segmentation. 

vii. oo m cl'jsioms 

We have presented a design that illustrates the teasihilitv ot' dynamic 
lin'<inq in a microcomputer environment. We have shown that there are only 
modest demands on the supporting lanquaqe translators, ooeratinq system, and 
hardware. On the other hand, the desinn is not in conflict with the more 
sophisticated, state-ot-the-art capabilities that can be expected tor micro- 
computers ot the tuture. Furthermore, the performance cost is quite moderate: 
the operations tor the first reterence are essentially those ot the tradi- 
tional lin'<inq loader. Subsequently we require about three additional 
instructions per external call and about two per external data reterence. 
Thus, we conclude that it is Possible and practical to include the substantial 
benefits ot dynamic linking in the set ot capabilities tor present and tuture 
microcomputers. 
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